home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 489 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.7 KB

  1. From: mk@anuurn.do.open.de (Martin Koehling)
  2. Subject: Re: mint-aware HD driver
  3. Date: Sun, 12 Sep 1993 21:50:38 MEZ
  4. Mime-Version: 1.0
  5.  
  6. Claus Brod <clausb@hpbeo79.bbn.hp.com> writes:
  7.  
  8. >> I was thinking about the problems with interrupt driven HD drivers,
  9. >> that cause mint not to block while doing disk access.
  10. >> One problem is that we would need a kind of semaphore for the dma hardware
  11. >> as it has to be locked against duplicate accesses at the same time.
  12. >
  13. >This is not a problem at all if we have a general /dev/scsi driver.
  14. >In this case, any process that wants to access SCSI hardware
  15. >directly would Fopen() that driver, and MiNT could apply its
  16. >usual restrictions against multiple access. We don't need semaphores
  17. >if there is only *one* official SCSI driver. Such a driver should,
  18. >however, probably have a Fcntl() mode to query its status, i.e. if
  19. >the SCSI channel is currently used by it.
  20. >
  21. >> What do you think about it?
  22. >
  23. >I think this is one of the less important problems. It's much more
  24. >important to have a reentrant GEMDOS, or else the whole project
  25. >comes to a grinding halt. That's exactly the point where my own driver
  26. >currently is. I haven't found the time yet to implement such a thing
  27. >in the MiNT kernel myself.
  28.  
  29. I don't think it's strictly necessary to re-implement GEMDOS right now -
  30. simply putting something like
  31.  
  32.     Psemaphore(2,'GEMD',-1L) ;  /* request GEMDOS Semaphore */
  33.  
  34. /before/ and something like
  35.  
  36.     Psemaphore(3,'GEMD',-1L) ;  /* release GEMDOS Semaphore */
  37.  
  38. /after/ any GEMDOS calls in tosfs.c should protect GEMDOS from any
  39. reentrant calls.
  40.  
  41. Or are there some hidden problems I'm overlooking?
  42. -- 
  43.  Martin Koehling | mk@anuurn.do.open.de | Martin_Koehling@un.maus.ruhr.de
  44.